Projet Zuul: Exercice 7.45 (optionnel)

Forum des exercices du projet Zuul

Exercice 7.45 (optionnel)

Vous êtes abonné à cette discussion. Cliquez pour vous désabonner.

Add locked doors to your game. The player needs to find (or otherwise obtain) a key to open a door.

Une pièce peut avoir certaines de ses portes ouvertes, et d'autres fermées.
Une clé doit être prise par le joueur avant de pouvoir ouvrir ou fermer une porte.
Elle fonctionne des 2 côtés de la porte.
Plusieurs clés différentes doivent pouvoir être gérées, et s'il y a plusieurs portes fermées à clé, il faut une clé différente pour ouvrir chacune d'entre-elles.
Selon le scénario, une porte peut se reverrouiller automatiquement ou non.

Conseil : Il est temps de créer une classe Door et, si vous ne l'aviez pas déjà fait pour l'exercice 7.43, de reconsidérer la réalisation de cet exercice.

Permalien | Modifier | Supprimer | Répondre

J'ai réalisé l'exercice sans ajouter de classe "Door", est-ce grave?

Si vous souhaitez faire correctement cet exercice optionnel, il faut créer une classe Door.

Il y a de grandes chances pour que votre implémentation actuelle sans classe Door ne respecte pas tous les conseils qui vous ont été donnés depuis le début du chapitre 7 ...

Si je comprends bien, il faut que les directions donnent sur les portes et les portes sur les rooms. Donc nous devons refaire tout nos hashMap précédent, est-ce bien ça ?

Rappel : cet exercice est optionnel.

Il y a une idée moins coûteuse : simplement ajouter une HashMap de Doors.

Bonjour,

Je n'ai pas très bien compris la principe de la classe Door.

Doit-elle seulement contenir un attribut boolean et seulement deux méthodes: un getter et un setter(pour ouvrir la porte si le joueur a la clé)?

Et faut-il créer une hashmap de portes dans createRoom ou ajouter un attribut de type Door à la classe Room?

Ainsi il suffirait d'effectuer un test avant de déplacer le joueur (voir si l'attribut de door est true ou false)

Je me demande aussi si il est judicieux de créer deux nouvelles classes : trapDoor et lockDoor qui hériteraient de la classe Door

Bonjour Monsieur,

Ce qui me gène le plus dans cet exercice c'est: Où placer les portes ? Les portes devant logiquement se trouver entre deux salles afin de les séparer on ne peut pas placer nos portes dans les salles. Comment faire ?

Suite à un pb technique, je viens seulement d'être prévenu de votre message.

La façon la plus simple à laquelle je pense est de prévoir une HashMap de portes qui se "superpose" à la HashMap d'exits.
Lorsque vous avez bien une pièce dans une direction donnée, vous regardez s'il y a une porte, et dans ce cas, si on peut la traverser.

Un étudiant a écrit :

Je
 suis actuellement à l’exercice 7.45 et en lisant les commentaires, j’ai
 une question concernant le choix d’implémentation de la classe Door :

1) Faut-il ajouter une nouvelle hashMap <String, Door> et la 
remplir un peu de la même manière que pour la hashmap des sorties 
(String la direction et Door qui contient seulement un attribut booléen 
pour savoir si la porte est ouverte ou fermée).

2) Faut il modifier la hashmap des sorties en une hashmap <String, 
Door> et dans ce cas, Door contient un attribut booléen et un 
attribut Room (la pièce voisine). Et cela nécessiterait de réécrire toutes les méthodes liées à cette hashmap.

1) D'après l'énoncé, Door ne contient pas qu'un booléen puisqu'elle doit connaître la clé qui peut l'ouvrir. L'absence de cet Item signifierait que cette porte ne peut être fermée à clé.

2) Pour ne pas avoir à effectuer toutes ces modifications, il vaut mieux superposer une nouvelle HashMap de Door à la HashMap de Room existante (comme indiqué dans une ou deux précédentes réponses ci-dessus).

Un étudiant a écrit :

Pour l'exercice looked doors j'ai compris qu'il faut une classe Door qui possède comme attribut un booléen qui indique si la porte peut être franchi ou non, et un attribut pour la clé de la porte. La clé sera bien un attribut de type Item ?

De plus, je ne comprends pas quand vous dites de prévoir une HashMap de Door qui se superpose à celle d'Exits.

Concernant la HashMap de Door, elle doit se trouver dans la classe Room je suppose ? Mais je ne vois pas quelle sera la clé qui sera associée à la valeur Door dans la déclaration de la HashMap.

Enfin, lorsque l'énoncé dit " Plusieurs clés différentes doivent pouvoir être gérées, et s'il y a plusieurs portes fermées à clé, il faut une clé différente pour ouvrir chacune d'entre-elles."

Je suppose qu'une HashMap de clés interviendra sûrement quelque part ? Mais je ne vois pas où.

> Pour l'exercice looked doors j'ai compris qu'il faut une classe Door qui possède comme attribut un booléen
> qui indique si la porte peut être franchi ou non, et un attribut pour la clé de la porte. La clé sera bien un attribut de type Item ?

Oui, une clé est un Item comme un autre ...

> De plus, je ne comprends pas quand vous dites de prévoir une HashMap de Door qui se superpose à celle d'Exits.

Elle se "superpose" car elle aura les mêmes clés : à chaque fois que vous aurez une exit (Room) dans une certaine direction, vous pourrez avoir une Door dans cette même direction.

> Concernant la HashMap de Door, elle doit se trouver dans la classe Room je suppose ?

Forcément puisqu'elle est complémentaire de celle des exits

> Mais je ne vois pas quelle sera la clé qui sera associée à la valeur Door dans la déclaration de la HashMap.
>

Exactement la même que pour les exits : la direction !

> Enfin, lorsque l'énoncé dit " Plusieurs clés différentes doivent pouvoir être gérées,
> et s'il y a plusieurs portes fermées à clé, il faut une clé différente pour ouvrir chacune d'entre-elles."

> Je suppose qu'une HashMap de clés interviendra sûrement quelque part ? Mais je ne vois pas où.

Non, aucun besoin de regrouper toutes les clés dans une HashMap.
Les clés sont placées dans des pièces comme les autres items, et on mémorise dans chaque porte la clé qui l'ouvre.

Bonjour,

j'ai réalisé une hashmap de Door superposée à la HashMap de Room comme vous l'aviez conseillé et le projet marche tout à fait.

Cependant deux problèmes me dérangent, le premier est que je trouverai plus logique de n'avoir qu'un porte par connexion entre pièces ce que je n'ai pas réussi à faire sans détruire l'architecture de la class Room. Le second est la commande back qui ne peut pas regarder la porte vers l'ancienne pièces.
C'est à dire si je me trouve dans une pièce je ne peux pas regarder si la porte vers l'ancienne pièce est fermé ou pas puisque je ne connais pas la direction.

J'aurais vraiment besoin que vous puissiez apporter des réponses à mes questions qui me travaillent depuis un moment déjà.

Bien à vous.

Pour le premier problème, vous l'avez bien résumé : difficile de n'avoir qu'une porte pour les 2 directions opposées sans "tout casser".

Pour le second problème, si on accepte qu'il y ait autant de portes que de sorties (donc une dans chaque sens entre deux pièces voisines), il ne devrait pas y avoir de difficulté pour que back accède à la bonne porte (comme elle accède à la bonne sortie dans l'exercice sur la TrapDoor).

Revenir à Généralités

Projet Zuul de conception orientée objet en Java d'un jeu d'aventure

Forum des exercices du projet Zuul

Exercice 7.45 (optionnel)

Navigation

Administration

Navigation

Administration